Add confirmed repository deletion tool - #3076

Reviewed this closely because it is destructive and security-sensitive. Two blockers, both reproducible.

Blocker 1: the confirmation does nothing in stdio mode

StateSealer is set in one place, pkg/http/server.go:175. internal/ghmcp never sets it, so requestStateSealerFromDeps returns nil in stdio and every binding check is skipped: no request state, no target binding, no repository ID check, no TTL.

What is left is confirmation.Content["repository_name"] == owner + "/" + repo. Both sides come from the client. InputResponses is client-controlled, and with a nil sealer nothing ties it to a server-issued InputRequests.

I called the handler directly with BaseDeps{} (no sealer), one tools/call, empty RequestState, and InputResponses filled in by the caller:

IsError            = false
result             = "Repository owner/repo was deleted."
DELETE calls       = 1
identity GET calls = 0
round trips used   = 1 (elicitation never requested)

The repository is deleted in one round trip and the user is never asked anything.

This is also why invokeDeleteRepository in repositories_test.go passes: it builds a single request with InputResponses already populated, which is the same shape as the bypass. The happy-path test does not exercise a real confirmation.

stdio is the primary target for this server, so the tool ships without the control it advertises.

func TestStdioModeConfirmationIsBypassable(t *testing.T) {
	client := NewMockedHTTPClient(
		WithRequestMatchHandler(DeleteReposByOwnerByRepo,
			mockResponse(t, http.StatusNoContent, nil)),
	)
	deps := BaseDeps{Client: mustNewGHClient(t, client)}
	require.Nil(t, deps.GetRequestStateSealer()) // stdio never configures one

	tool := DeleteRepository(translations.NullTranslationHelper)
	request := createMCPRequest(map[string]any{"owner": "owner", "repo": "repo"})

	// Server never issued an elicitation. Client asserts the user confirmed.
	request.Params.InputResponses = mcp.InputResponseMap{
		deleteRepositoryConfirmationID: &mcp.ElicitResult{
			Action:  "accept",
			Content: map[string]any{deleteRepositoryConfirmationField: "owner/repo"},
		},
	}
	request.Params.RequestState = ""

	result, err := tool.Handler(deps)(ContextWithDeps(context.Background(), deps), &request)
	require.NoError(t, err)
	require.False(t, result.IsError) // passes: repository deleted
}

Blocker 2: scope checks changed from ANY to ALL for every tool

NewTool and NewToolFromHandler now set RequiredScopeGroups on every tool, and CreateToolScopeFilter uses HasRequiredScopeGroups whenever that field is non-empty.

HasRequiredScopes is ANY-of. HasRequiredScopeGroups is ALL-of. So every tool declaring more than one scope changes meaning, not just the new one.

Three existing tools declare {Repo, ReadOrg}:

• pkg/github/issue_fields.go:132 — list_issue_fields
• pkg/github/issues.go:1112 — list_issue_types
• pkg/github/ui_tools.go:71 — ui_get

Running CreateToolScopeFilter([]string{"repo"}) against origin/main and this branch:

list_issue_types is affected the same way.

repo is the common PAT scope, so these tools disappear for a lot of users, with no error and no migration note. The added scope tests only cover a synthetic tool, so nothing catches this.

Consequence: the README is now wrong

cmd/github-mcp-server/generate_docs.go:224 still states the old rule:

// Scope filtering uses "any of" semantics (see scopes.HasRequiredScopes),
// so when multiple required scopes are listed, render them as alternatives
// rather than implying all are required.

The generator was not updated, so the README documents "any of" for tools that now require all three entries:

• README.md:947 — list_issue_fields: repo, read:org
• README.md:953 — list_issue_types: repo, read:org
• README.md:1312 — delete_repository: delete_repo, repo

delete_repository is documented as needing either scope; it needs both. script/generate-docs passes because it regenerates the same wrong text.

To unblock

1. Make the sealer mandatory for this tool. Refuse the deletion when there is no sealer, or give stdio one. Today the check is skipped exactly where the tool is most used.
2. Replace the happy-path test with one that goes through a real elicitation round trip, so a fabricated InputResponses cannot pass.
3. Revert the global ANY to ALL change. Apply the conjunctive rule only to delete_repository.
4. Add a regression test pinning list_issue_fields, list_issue_types and ui_get as visible with a repo-only token.
5. Update generate_docs.go to render conjunctive groups, then regenerate the README.
6. Cover the untested branches on the delete path, starting with RequestState == "" (repositories.go:817). DeleteRepository is at 79.2% and most of the uncovered branches are the refusal paths.

The availability work in pkg/inventory is solid, the {}-means-form handling correctly matches the go-sdk, and the AES-256-GCM usage looks right. The problem is that the guarantee only holds on the HTTP path.

Addressed both blockers from the latest review:

• delete_repository now fails closed without a request-state sealer, and stdio creates a process-local random sealer at startup. The handler tests now perform a real issue-and-retry flow and explicitly cover fabricated inputResponses plus missing requestState.
• Restored legacy ANY-of semantics for existing multi-scope tools. Conjunctive scope groups are now applied only to delete_repository; regression coverage pins list_issue_fields, list_issue_types, and ui_get as visible to repo-only tokens.
• Generated docs now label delete_repository scopes as all required.

Full lint and race suites pass on 2dce589e.